home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Danny Amor's Online Library
/
Danny Amor's Online Library - Volume 1.iso
/
html
/
rfc
/
rfcxxxx
/
rfc1127
< prev
next >
Wrap
Text File
|
1995-07-25
|
40KB
|
1,617 lines
Network Working Group R. Braden
Request for Comments: 1127 ISI
October 1989
A Perspective on the Host Requirements RFCs
Status of This Memo
This RFC is for information only; it does not constitute a standard,
draft standard, or proposed standard, and it does not define a
protocol. Distribution of this memo is unlimited.
Summary
This RFC contains an informal summary of the discussions and
conclusions of the IETF Working Group on Host Requirements while it
was preparing the Host Requirements RFCs. This summary has several
purposes: (1) to inform the community of host protocol issues that
need further work; (2) to preserve some history and context as a
starting point for future revision efforts; and (3) to provide some
insight into the results of the Host Requirements effort.
1. INTRODUCTION
A working group of the Internet Engineering Task Force (IETF) has
recently completed and published a monumental standards document on
software requirements for Internet hosts [RFC-1122, RFC-1123]. This
document has been published as two RFC's: "Requirements for Internet
Hosts -- Communication Layers", referred to here as "HR-CL", and
"Requirements for Internet Hosts -- Application and Support",
referred to here as "HR-AS". Together, we refer to them as the Host
Requirements RFCs, or "HR RFCs".
Creation of the Host Requirements document required the dedicated
efforts of about 20 Internet experts, with significant contributions
from another 20. The Host Requirements working group held 7 formal
meetings over the past 20 months, and exchanged about 3 megabytes of
electronic mail. The HR RFCs went through approximate 20 distinct
drafts.
This group of people struggled with a broad range of issues in host
implementations of the Internet protocols, attempting to reconcile
theoretical and architectural concerns with the sometimes conflicting
imperatives of the real world. The present RFC recaps the results of
this struggle, with the issues that were settled and those that
remain for future work. This exegesis has several goals:
Braden [Page 1]
RFC 1127 Perspective on Host Requirements October 1989
(1) to give the Internet technical community some insight into the
results of the host requirements effort;
(2) to inform the community of areas that need further work; and
(3) to preserve some history and context of the effort as a starting
point for a future revision.
1.1 GOALS OF THE HOST REQUIREMENTS RFCs
The basic purpose of the Host Requirements RFCs is to define the
requirements for Internet host software. However, the document goes
far beyond a simple prescription of requirements, to include:
(a) a bibliography of the documents essential to an implementor;
(b) corrections and updates to the original standards RFC's;
(c) material to fill gaps in the previous specifications;
(d) limitations on implementation choices, where appropriate;
(e) clarification of important issues and the intent of the
protocols; and
(f) documentation of known solutions to recurring problems as well
as implementation hints.
Broadly speaking, the Host Requirements working group started from
the following goals for Internet host software:
(1) Interoperability
(2) Extensibility
(3) Functionality
(4) Efficiency
(5) Architectural Purity
Of these, interoperability was clearly preeminent, while
architectural purity had the lowest priority. It is more difficult
to assign relative importance to extensibility, functionality, and
efficiency, as it varied from one topic to another.
At a more technical level, the working group pursued a set of general
goals that included the following:
Braden [Page 2]
RFC 1127 Perspective on Host Requirements October 1989
* Discourage hosts from unexpectedly acting as gateways.
* Discourage the use of bad IP addresses.
* Eliminate broadcast storms.
* Discourage gratuitous Address Mask Reply messages.
* Facilitate the use IP Type-of-Service for routing and queueing.
* Encourage implementations of IP multicasting.
* Encourage TCP connection robustness.
* Encourage (mandate!) implementation of known TCP performance
enhancements.
* Encourage user interfaces that support the full capabilities of
the protocols.
* Encourage more complete implementations of FTP.
* Encourage robust mail delivery
* Discourage the source-routing of mail in the Internet.
* Encourage error logging.
In addition to these general technical goals, the working group
decided to discourage the use of certain protocol features: e.g., the
IP Stream Id option, ICMP Information Request and Reply messages, the
RFC-795 TOS mappings, WKS records in the Domain Name System, and FTP
Page structure.
The HR RFC tries to deal only with the software implementation, not
with the way in which that software is configured and applied. There
are a number of requirements on Internet hosts that were omitted from
the HR RFC as administrative or configuration issues.
The HR RFCs contain many, many detailed requirements and
clarifications that are straightforward and (almost) non-
controversial.
Indeed, many of these are simply restatements or reinforcement of
requirements that are already explicit or implicit in the original
standards RFC's. Some more cynical members of the working group
refer to these as "Read The Manual" provisions. However, they were
included in the HR RFCs because at least one implementation has
Braden [Page 3]
RFC 1127 Perspective on Host Requirements October 1989
failed to abide by these requirements. In addition, many provisions
of the HR RFCs are simply applications of Jon Postel's Robustness
Principle [1.2.2 in either RFC].
However, not all issues were so easy; the working group struggled
with a number of deep and controversial technical issues. Where the
result was a reasonable consensus, then definite, firm
recommendations and requirements resulted. We list these settled
issues in Section 2. Section 2 also lists a number of areas where
the HR RFCs fill gaping holes in the current specifications by giving
extended discussions of particular issues.
However, in some other cases the working group was unable to reach a
crisp decision or even a reasonable consensus; we list these open
issues in Section 3. Future discussion is needed to ascertain which
of these issues really do have "right answers", and which can
reasonably be left as implementation choices. Section 4 contains
some other areas that the working group did not tackle but which need
further work outside the context of the HR RFCs (although the outcome
may be reflected in a future revision). Finally, Appendix I lists
specific issues for consideration by a future HR RFC revision effort,
while Appendix II lists the issues that are relevant to a revision of
the Gateway Requirements RFC.
It should be noted that this categorization of issues is imperfect; a
few issues appear (legitimately) in more than one category.
For brevity, we do not attempt to define all the terminology or
explain all the concepts mentioned here. For those cases where
further clarification is needed, we include (in square brackets)
references to the corresponding sections of the HR RFCs.
2. SETTLED ISSUES
Here are the areas in which the Host Requirements working group was
able to reach a consensus and take a definite stand.
- ARP Cache Management [CL 2.3.2.1]
Require a mechanism to flush out-of-date ARP cache entries.
- Queueing packets in ARP [CL 2.3.2.2]
Recommend that ARP queue unresolved packet(s) in the link layer.
- Ethernet/802.3 Interoperability [CL 2.3.3]
Impose interoperability requirements for Ethernet and IEEE 802.3
Braden [Page 4]
RFC 1127 Perspective on Host Requirements October 1989
encapsulation.
- Broadcast Storms [CL 2.4, 3.2.2]
Require many provisions to prevent broadcast storms.
In particular, require that the link-layer driver pass a flag to
the IP layer to indicate if a packet was received via a link-
layer broadcast, and require that this flag be used by the IP
layer.
- Bad IP addresses
Include numerous provisions to discourage the use of bad IP
addresses.
- Address Mask Replies [CL 3.2.2.9]
Discourage gratuitous ICMP Address Mask Reply messages.
- Type-of-Service
Include various requirements on IP, transport, and application
layers to make Type-of-Service (TOS) useful.
- Time-to-Live [CL 3.2.1.7]
Require that Time-to-Live (TTL) be configurable.
- Source Routing [CL 3.2.1.8(e)]
Require that host be able to act as originator or final
destination of a source route.
- IP Multicasting [CL 3.3.7]
Encourage implementation of local IP multicasting.
- Reassembly Timeout [CL 3.3.2]
Require a fixed reassembly timeout.
- Choosing a Source Address [CL 3.3.4.3, 3.4, 4.1.3.5, 4.2.3.7]
Require that an application on a multihomed host be able to
either specify which local IP address to use for a new TCP
connection or UDP request, or else leave the local address
"wild" and let the IP layer pick one.
Braden [Page 5]
RFC 1127 Perspective on Host Requirements October 1989
- TCP Performance [CL 4.2.12.15, 4.2.3.1-4]
Require TCP performance improvements.
- TCP Connection Robustness [CL 4.2.3.5, 4.2.3.9]
Encourage robustness of TCP connections.
- TCP Window Shrinking [CL 4.2.2.16]
Discourage the shrinking of TCP windows from the right.
- Dotted-Decimal Host Numbers [AS 2.1]
Recommend that applications be able to accept dotted-decimal
host numbers in place of host names.
- Telnet End-of-Line [AS 3.3.1]
Include compatibility requirements for Telnet end-of-line.
- Minimal FTP [AS 4.1.2.13]
Enlarge the minimum FTP implementation.
- Robust Mail Delivery [AS 5.3.2, 5.3.4, 6.1.3.4]
Recommend the use of long timeouts and of alternative addresses
for multihomed hosts, to obtain robust mail delivery.
- Source-Routing of Mail [AS 5.2.6, 5.2.16, 5.2.19]
Discourage the use of source routes for delivering mail. (This
was one of the few cases where the working group opted for the
architecturally pure resolution of an issue.)
- Fully-Qualified Domain Names [AS 5.2.18]
Require the use of fully-qualified domain names in RFC-822
addresses.
- Domain Name System Required [AS 6.1.1]
Require that hosts implement the Domain Name System (DNS).
- WKS Records Detracted [AS 2.2, 5.2.12, 6.1.3.6]
Recommend against using WKS records from DNS.
Braden [Page 6]
RFC 1127 Perspective on Host Requirements October 1989
- UDP Preferred for DNS Queries [AS 6.1.2.4, 6.1.3.2]
Require that UDP be preferred over TCP for DNS queries.
- DNS Negative Caching [AS 6.1.3.3]
Recommend that DNS name servers and resolvers cache negative
responses and temporary failures.
Finally, here is a list of areas in which the HR RFCs provide
extended discussion of issues that have been inadequately documented
in the past.
- ARP cache handling [CL 2.3.2.1]
- Trailer encapsulation [CL 2.3.1]
- Dead gateway detection algorithms [CL 3.3.1.4]
- IP multihoming models [CL 3.3.4]
(Note that this topic is also one of the significant contentious
issues; see the next section.)
- Maximum transmission unit (MTU and transport-layer maximum-
segment size (MSS) issues [CL 3.3.2, 3.3.3, 3.4, 4.1.4,
4.2.2.6]
- TCP silly-window syndrome (SWS) avoidance algorithms
[CL 4.2.3.3, 4.2.3.4]
- Telnet end-of-line issues [AS 3.3.1]
- Telnet interrupt/SYNCH usage [AS 3.2.4]
- FTP restart facility [AS 4.1.3.4]
- DNS efficiency issues [AS 6.1.3.3]
- DNS user interface: aliases and search lists [AS 6.1.4.3]
There are some other areas where the working group tried to produce a
more extended discussion but was not totally successful; one example
is error logging (see Appendix I below).
Braden [Page 7]
RFC 1127 Perspective on Host Requirements October 1989
3. OPEN ISSUES
For some issues, the disagreement was so serious that the working
group was unable to reach a consensus. In each case, some spoke for
MUST or SHOULD, while others spoke with equal fervor for MUST NOT or
SHOULD NOT. As a result, the HR RFCs try to summarize the differing
viewpoints but take no stand; the corresponding requirements are
given as MAY or OPTIONAL. The most notorious of these contentious
issues are as follows.
- Hosts forwarding source-routed datagrams, even though the hosts
are not otherwise acting as gateways [CL 3.3.5]
- The multihoming model [CL 3.3.4]
- ICMP Echo Requests to a broadcast or multicast address
[CL 3.2.2.6]
- Host-only route caching [CL 3.3.1.3]
- Host wiretapping routing protocols [CL 3.3.1.4]
- TCP sending an ACK when it receives a segment that appears to be
out-of-order [CL 4.2.2.21]
There was another set of controversial issues for which the HR RFCs
did take a compromise stand, to allow the disputed functions but
circumscribe their use. In many of these cases, there were one or
more significant voices for banning the feature altogether.
- Host acting as gateways [CL 3.1]
- Trailer encapsulation [CL 2.3.1]
- Delayed TCP acknowledgments [CL 4.2.3.2]
- TCP Keep-alives [CL 4.2.3.6]
- Ignoring UDP checksums [CL 4.1.3.4]
- Telnet Go-Aheads [AS 3.2.2]
- Allowing 8-bit data in Telnet NVT mode [AS 3.2.5]
Braden [Page 8]
RFC 1127 Perspective on Host Requirements October 1989
4. OTHER FUTURE WORK
General Issues:
(1) Host Initialization Procedures
When a host system boots or otherwise initializes, it needs
certain network configuration information in order to communicate;
e.g., its own IP address(es) and address mask(s). In the case of
a diskless workstation, obtaining this information is an essential
part of the booting process.
The ICMP Address Mask messages and the RARP (Reverse ARP) protocol
each provide individual pieces of configuration information. The
working group felt that such piecemeal solutions are a mistake,
and that a comprehensive approach to initialization would result
in a uniform mechanism to provide all the required configuration
information at once. The HR working group recommends that a new
working group be established to develop a unified approach to
system initialization.
(2) Configuration Options
Vendors, users, and network administrators all want host software
that is "plug-and-play". Unfortunately, the working group was
often forced to require additional configuration parameters to
satisfy interoperability, functionality, and/or efficiency needs
[1.2.4 in either RFC]. The working group was fully aware of the
drawbacks of configuration parameters, but based upon extensive
experience with existing implementations, it felt that the
flexibility was sometimes more important than installation
simplicity.
Some of the configuration parameters are forced for
interoperability with earlier, incorrect implementations. Very
little can be done to ease this problem, although retirement of
the offending systems will gradually solve it. However, it would
be desirable to re-examine the other required configuration
options, in an attempt to develop ways to eliminate some of them.
Link-Layer Issues:
(2) ARP Cache Maintenance
"Proxy ARP" is a link-layer mechanism for IP routing, and its use
results in difficult problems in managing the ARP cache.
Even without proxy ARP, the management dynamics of the IP route
Braden [Page 9]
RFC 1127 Perspective on Host Requirements October 1989
cache interact in subtle ways with transport-layer dynamics;
introducing routing via proxy ARP brings a third protocol layer
into the problem, complicating the inter-layer dynamics still
further.
The algorithms for maintaining the ARP cache need to be studied
and experimented with, to create more complete and explicit
algorithms and requirements.
(3) FDDI Bit-order in MAC addresses
On IEEE 802.3 or 802.4 LAN, the MAC address in the header uses the
same bit-ordering as transmission of the address as data. On
802.5 and FDDI networks, however, the MAC address in the header is
in a different bit-ordering from the equivalent 6 bytes sent as
data. This will make it hard to do MAC-level bridging between
FDDI and 802.3 LAN's, for example, although gateways (IP routers)
can still be used.
The working group concluded that this is a serious but subtle
problem with no obvious fix, and that resolving it was beyond the
scope of the HR working group.
IP-Layer Issues
(4) Dead Gateway Detection
A fundamental requirement for a host is to be able to detect when
the first-hop gateway has failed. The early TCP/IP
experimentation was based on the ARPANET, which provided explicit
notification of gateway failure; as a result, dead gateway
detection algorithms were not much considered at that time. The
very general guidelines presented by Dave Clark [RFC-816] are
inadequate for implementors. The first attempt at applying these
guidelines was the introduction of universal gateway pinging by
TOPS-20 systems; this quickly proved to be a major generator of
ARPANET traffic, and was squelched. The most widely used
implementation of the Internet protocols, 4.2BSD, solved the
problem in an extra-architectural manner, by letting the host
wiretap the gateway routing protocol (RIP). As a result of this
history, the HR working group was faced with an absence of
documentated techniques that a host conforming to the Internet
architecture could use to detect dead gateways.
After extensive discussion, the working group agreed on the
outline of an appropriate algorithm. A detailed algorithm was in
fact written down, to validate the discussion in the HR RFCs.
This algorithm, or a better one, should be tried experimentally
Braden [Page 10]
RFC 1127 Perspective on Host Requirements October 1989
and documented in a new RFC.
(5) Gateway Discovery
A host needs to discover the IP addresses of gateways on its
connected networks. One approach, begun but not finished by
members of the HR working group, would be to define a new pair of
ICMP query messages for gateway discovery. In the future, gateway
discovery should be considered as part of the complete host
initialization problem.
(6) MTU Discovery
Members of the HR working group designed IP options that a host
could use to discover the minimum MTU of a particular Internet
path [RFC-1063]. To be useful, the Probe MTU options would have
to be implemented in all gateways, which is an obstacle to its
adoption. Code written to use these options has never been
tested. This work should be carried forward; an effective MTU
choice will become increasingly important for efficient Internet
service.
(7) Routing Advice from Gateways
A working group member produced a draft specification for ICMP
messages a host could use to ask gateways for routing advice
[Lekashman]. While this is not of such pressing importance as the
issues listed previously, it deserves further consideration and
perhaps experimentation.
(8) Dynamic TTL Discovery
Serious connectivity problems have resulted from host software
that has too small a TTL value built into the code. HR-CL
specifies that TTL values must be configurable, to allow TTL to be
increased if required for communication in a future Internet;
conformance with this requirement would solve the current
problems. However, configurable parameters are an operational
headache, so it has been suggested that a host could have an
algorithm to determine the TTL ("Internet diameter") dynamically.
Several algorithms have been suggested, but considerably more work
would be required to validate them. This is a lower-priority
problem than issues (4)-(6).
(9) Dynamic Discovery of Reassembly Timeout Time
The maximum time for retaining a partially-reassembled datagram is
another parameter that creates a potential operational headache.
Braden
15 r (In) s
0 r (ternet) s
14 r 119 c
0 r (orkshop) s
14 r (in) s
15 r (San) s
0 r (ta) s
0 2529 p (Clara,) s
13 r (Jan) s
0 r (uary) s
-3 r 44 c
11 r (1989.) s
cmr10.1643-34 @sf
0 2678 p (Estrin) s
1669 r ([P) s
0 r (age) s
14 r (5]) s
@eop
4 @bop0
cmbx10.2160-55 @sf
[<007FFFF8007FFFF8007FFFF80000FF000000FF000000FF000000FF000000FF000000FF000000FF00FFFFFFF8FFFFFFF8FFFF
FFF8E0007F0070007F0038007F001C007F000E007F000F007F0007007F0003807F0001C07F0000E07F0000F07F0000707F00
00387F00001C7F00000E7F00000F7F0000077F000003FF000001FF000000FF000000FF0000007F0000003F0000001F000000
0F0000000700> 32 39 -2 0 34.370] 52 @dc
[<00000E00000700000000001F00000F80000000001F00000F80000000001F80001F80000000003F80001FC0000000003F8000
1FC0000000003FC0003FC0000000007FC0003FE0000000007FC0003FE000000000FFE0007FF000000000FFE0007FF0000000
00FFF000FFF000000001FFF000FFB800000001FF7000FFB800000001FF7801FFB800000003FE3801FF1C00000003FE3801FF
1C00000007FE1C03FE1E00000007FC1C03FE0E00000007FC1E07FE0E0000000FFC0E07FC070000000FF80E07FC070000001F
F80F0FFC078000001FF0070FF8038000001FF0070FF8038000003FF0039FF003C000003FE0039FF001C000003FE003FFF001
C000007FE001FFE000E000007FC001FFE000E00000FFC000FFE000F00000FF8000FFC000700000FF8000FFC000700001FF80
00FF8000780001FF0000FF8000380001FF0001FF8000380003FE0001FF00001C0003FE0001FF00001C00FFFFF87FFFF807FF
F0FFFFF87FFFF807FFF0FFFFF87FFFF807FFF0> 72 41 -1 0 71.065] 87 @dc
[<7FFF0FFFE3FFF87FFF0FFFE3FFF87FFF0FFFE3FFF807F000FE003F8007F000FE003F8007F000FE003F8007F000FE003F8007
F000FE003F8007F000FE003F8007F000FE003F8007F000FE003F8007F000FE003F8007F000FE003F8007F000FE003F8007F0
00FE003F8007F000FE003F8007F000FE003F8007F000FE003F8007F000FE003F8007F000FE003F8007F000FE003F8007F000
FE003F8007F000FE003F8007F000FE003F80FFFFFFFFFFFF80FFFFFFFFFFFF80FFFFFFFFFFFF8007F000FE00000007F000FE
00000007F000FE00000007F000FE00000007F000FE001E0007F001FE003F0007F001FE007F8007F001FE007F8007F001FE00
7F8003F801FF007F8003FC01FF803F8001FE00FFC01F00007FC0FFF03E00001FFFE3FFFC000003FF807FF000> 56 42 -1 0 57.283] 14 @dc
cmr8.1500-13 @sf
[<0FE01FF83C3C701C700E600EE00EE00EE00EF01EF81CFFF8EFF0E08070007000781C3C1C1E1C0FF803F0> 16 21 -1 0 17.642] 54 @dc
[<0E000E000E000E000E000E0006000700070003000380018001C000E00060C070C038E01C7FFE7FFE7FFE6000> 16 22 -2 0 17.642] 55 @dc
cmr6.1500-4 @sf
[<1F003FC071C060E0C060C060C060E0E0FFC0FFC0C200600071C039C01FC00F80> 16 16 -1 0 15.220] 54 @dc
cmr9.1500-18 @sf
[<7F8FE3FC0E0380E00E0380E00E0380E00E0380E00E0380E00E0380E00E0380E00E0380E00E0380E00E0380E00E0380E00E03
80E00E0380E00E0380E0FFFFFFE00E0380000E0380000E0380000E0380000E0380C00E0781E0060781E00703C0E001C370C0
007C1F00> 32 26 0 0 31.997] 14 @dc
[<00800100020004000C00080018003000300030006000600060006000E000E000E000E000E000E000E000E000E000E0006000
600060006000300030003000180008000C000400020001000080> 16 38 -3 10 14.932] 40 @dc
[<8000400020001000180008000C00060006000600030003000300030003800380038003800380038003800380038003800300
0300030003000600060006000C00080018001000200040008000> 16 38 -2 10 14.932] 41 @dc
[<FFFFC00F00F00F00780F003C0F001C0F001E0F001E0F001E0F001E0F001C0F003C0F00380F00F00FFFC00F01E00F00700F00
780F003C0F003C0F003C0F003C0F003C0F00380F00700F00E0FFFF80> 24 26 -1 0 27.195] 66 @dc
[<FFC0FFC0> 16 2 0 -7 12.799] 45 @dc
[ 1500 ] /cmti9.1500-21 @newfont
cmti9.1500-21 @sf
[<3E3C7FFEF3F7E0F3E073E07BE078E038E038F03C703C781C383C1E7E0FFE03EE> 16 16 -4 0 19.602] 97 @dc
[<700F80780FC0781CC0381EE0380E603C0E603C0F001C07001C07001E0700DE0780CF0380CF8380EFC7807EFF003C7E00> 24 16 -3 0 21.562] 110 @dc
[<3E3C007FFE00F3F700E0F300E07300E07B00E07800E03800E03800F03C00703C00781C00383C001E7E000FFE0003EE00000E
00000F00000F00000700000700000780000780000380001F80001F80> 24 26 -4 0 19.602] 100 @dc
cmr6.1500-4 @sf
[<1C001C001C001C001C001C000C000E000E00060007000380C1C0C0E07FE07FE06000> 16 17 -2 0 15.220] 55 @dc
cmr9.1500-18 @sf
[<FFFFF80F00780F001C0F000C0F00040F00040F00040F00020F00020F02000F02000F02000F06000FFE000F06000F02000F02
000F02000F00040F00040F00040F000C0F00080F00180F0038FFFFF8> 24 26 -1 0 26.128] 69 @dc
[<306078F0F9F0B1608100810081004080408020401830> 16 11 -5 -15 19.198] 92 @dc
[<C18020401020102008100810081068D0F9F0F1E060C0> 16 11 -1 -15 19.198] 34 @dc
[<0F8030E040704038E038F03CF03C703C003C003C00380038207030602FC0200020002000200020003FC03FE03FF03018> 16 24 -2 0 19.198] 53 @dc
4 @bop1
cmsl10.1643-38 @sf
0 -99 p (RF) s
0 r 67 c
14 r (1125) s
518 r 80 c
-1 r (olicy) s
14 r (Requiremen) s
0 r (ts) s
517 r (No) s
0 r 118 c
-2 r (em) s
-1 r 98 c
0 r (er) s
15 r (1989) s
cmbx10.2160-55 @sf
0 45 p 52 c
69 r (Wh) s
-1 r 121 c
22 r (the) s
23 r (problem) s
23 r (is) s
22 r (di\016cult) s
cmr10.1643-34 @sf
0 186 p (Before) s
18 r (pro) s
1 r (ceeding) s
19 r (with) s
18 r (our) s
18 r (description) s
18 r (of) s
18 r (top) s
1 r (ology) s
18 r (and) s
19 r 112 c
1 r (olicy) s
18 r (requiremen) s
0 r (ts) s
17 r (this) s
18 r (section) s
18 r (outlines) s
0 242 p (sev) s
0 r (eral) s
19 r (assumptions) s
20 r (and) s
21 r (constrain) s
-1 r (ts,) s
21 r (namely:) s
31 r (the) s
20 r (lac) s
0 r 107 c
19 r (of) s
20 r (global) s
21 r (authorit) s
0 r 121 c
-4 r 44 c
20 r (the) s
21 r (need) s
20 r (to) s
20 r (supp) s
2 r (ort) s
0 299 p (net) s
0 r 119 c
-2 r (ork) s
13 r (resource) s
14 r (sharing) s
13 r (as) s
14 r 119 c
0 r (ell) s
12 r (as) s
14 r (net) s
-1 r 119 c
-1 r (ork) s
13 r (in) s
-1 r (terconnection,) s
13 r (the) s
14 r (complex) s
13 r (and) s
14 r (dynamic) s
14 r (mapping) s
13 r (of) s
0 355 p (users) s
15 r (to) s
16 r (ADs) s
15 r (and) s
15 r (privileges,) s
15 r (and) s
16 r (the) s
15 r (need) s
15 r (for) s
16 r (accoun) s
-1 r (tabilit) s
-1 r 121 c
14 r (across) s
16 r (ADs.) s
20 r (These) s
16 r (assumptions) s
15 r (limit) s
0 412 p (the) s
15 r (solution) s
15 r (space) s
15 r (and) s
16 r (raise) s
15 r 99 c
-1 r (hallenging) s
15 r (tec) s
-1 r (hnical) s
15 r (issues.) s
71 507 p (The) s
16 r (purp) s
2 r (ose) s
17 r (of) s
16 r 112 c
2 r (olicy) s
17 r (based) s
16 r (routing) s
17 r (is) s
17 r (to) s
17 r (allo) s
0 r 119 c
16 r (ADs) s
17 r (to) s
16 r (in) s
0 r (terconnect) s
16 r (and) s
17 r (share) s
17 r (computer) s
17 r (and) s
0 564 p (net) s
0 r 119 c
-2 r (ork) s
13 r (resources) s
13 r (in) s
14 r 97 c
13 r (con) s
0 r (trolled) s
12 r (manner.) s
20 r (Unlik) s
-1 r 101 c
13 r (man) s
-1 r 121 c
13 r (other) s
13 r (problems) s
13 r (of) s
14 r (resource) s
13 r (con) s
0 r (trol,) s
13 r (there) s
13 r (is) s
0 620 p (no) s
14 r (global) s
15 r (authorit) s
0 r 121 c
-4 r 46 c
19 r (Eac) s
0 r 104 c
13 r (AD) s
14 r (de\014nes) s
15 r (its) s
14 r 111 c
0 r (wn) s
14 r 112 c
1 r (olicies) s
14 r (with) s
15 r (resp) s
1 r (ect) s
14 r (to) s
15 r (its) s
14 r 111 c
0 r (wn) s
14 r (tra\016c) s
14 r (and) s
14 r (resources.) s
0 676 p (Ho) s
0 r 119 c
-2 r (ev) s
-1 r (er,) s
22 r (while) s
21 r 119 c
0 r 101 c
20 r (assume) s
21 r (no) s
21 r (global) s
22 r (authorit) s
-1 r 121 c
-3 r 44 c
21 r (and) s
21 r (no) s
22 r (global) s
21 r 112 c
1 r (olicies,) s
23 r 119 c
-1 r 101 c
21 r (recognize) s
21 r (that) s
21 r (com-) s
0 733 p (plete) s
18 r (autonom) s
-1 r 121 c
17 r (implies) s
18 r (no) s
17 r (dep) s
2 r (endence) s
17 r (and) s
18 r (therefore) s
18 r (no) s
17 r (comm) s
0 r (unication.) s
27 r (The) s
17 r 109 c
0 r (ulti-organization) s
0 789 p (in) s
0 r (ternets) s
12 r (addressed) s
13 r (here) s
14 r (ha) s
-1 r 118 c
-1 r 101 c
12 r (inheren) s
0 r 116 c
12 r (regions) s
14 r (of) s
13 r (autonom) s
0 r 121 c
-4 r 44 c
13 r (as) s
13 r 119 c
0 r (ell) s
12 r (as) s
13 r (requiremen) s
0 r (ts) s
12 r (for) s
13 r (in) s
0 r (terdep) s
0 r (en-) s
0 846 p (dence.) s
20 r (Our) s
14 r (mec) s
0 r (hanisms) s
13 r (should) s
14 r (allo) s
0 r 119 c
13 r (ADs) s
14 r (to) s
14 r (design) s
14 r (their) s
14 r 98 c
1 r (oundaries,) s
15 r (instead) s
14 r (of) s
14 r (requiring) s
14 r (that) s
14 r (the) s
0 902 p 98 c
1 r (oundaries) s
15 r 98 c
2 r 101 c
15 r (either) s
15 r (imp) s
1 r (enetrable) s
15 r (or) s
16 r (eliminated.) s
71 998 p (One) s
17 r (of) s
18 r (the) s
17 r (most) s
18 r (problematic) s
18 r (asp) s
1 r (ects) s
17 r (of) s
18 r (the) s
18 r 112 c
1 r (olicy) s
17 r (routing) s
18 r (requiremen) s
0 r (ts) s
16 r (iden) s
0 r (ti\014ed) s
17 r (here) s
17 r (is) s
18 r (the) s
0 1054 p (need) s
19 r (to) s
18 r (supp) s
1 r (ort) s
19 r 98 c
1 r (oth) s
19 r (net) s
0 r 119 c
-2 r (ork) s
18 r (resource) s
19 r (sharing) s
18 r (and) s
19 r (in) s
0 r (terconnection) s
17 r (across) s
19 r (ADs.) s
30 r (An) s
19 r (example) s
19 r (of) s
0 1111 p (resource) s
16 r (sharing) s
16 r (is) s
17 r 116 c
-1 r 119 c
-1 r 111 c
15 r (ADs) s
17 r (\(e.g.,) s
16 r (agencies,) s
17 r (divisions,) s
16 r (companies\)) s
16 r (sharing) s
17 r (net) s
-1 r 119 c
-1 r (ork) s
15 r (resources) s
17 r (\(e.g.,) s
0 1167 p (links,) s
19 r (or) s
18 r (gatew) s
0 r 97 c
-2 r (ys) s
17 r (and) s
19 r (links\)) s
18 r (to) s
18 r (tak) s
0 r 101 c
17 r (adv) s
-2 r (an) s
-1 r (tage) s
17 r (of) s
18 r (economies) s
18 r (of) s
18 r (scale.) s
29 r (Pro) s
0 r (viding) s
17 r (transit) s
18 r (services) s
0 1224 p (to) s
22 r (external) s
22 r (ADs) s
22 r (is) s
22 r (another) s
21 r (example) s
22 r (of) s
22 r (net) s
0 r 119 c
-1 r (ork) s
21 r (resource) s
22 r (sharing.) s
40 r (In) s
0 r (terconnection) s
21 r (is) s
21 r (the) s
22 r (more) s
0 1280 p (common) s
19 r (example) s
19 r (of) s
19 r (ADs) s
19 r (in) s
0 r (terconnecting) s
18 r (their) s
19 r (indep) s
2 r (enden) s
-1 r (tly) s
19 r (used) s
19 r (net) s
-1 r 119 c
-1 r (ork) s
18 r (resources) s
19 r (to) s
20 r (ac) s
-1 r (hiev) s
-1 r 101 c
0 1337 p (connectivit) s
0 r 121 c
14 r (across) s
15 r (the) s
15 r (ADs,) s
15 r (i.e.,) s
15 r (to) s
15 r (allo) s
0 r 119 c
14 r 97 c
15 r (user) s
15 r (in) s
15 r (one) s
15 r (AD) s
15 r (to) s
15 r (comm) s
0 r (unicate) s
14 r (with) s
15 r (users) s
15 r (in) s
15 r (another) s
0 1393 p (AD.) s
19 r (In) s
20 r (some) s
19 r (resp) s
1 r (ects,) s
21 r (net) s
-1 r 119 c
-1 r (ork) s
19 r (resource) s
19 r (con) s
0 r (trol) s
18 r (is) s
19 r (simpler) s
20 r (than) s
19 r (net) s
0 r 119 c
-1 r (ork) s
18 r (in) s
0 r (terconnection) s
18 r (con) s
0 r (trol) s
0 1450 p (since) s
17 r (the) s
17 r 112 c
1 r (oten) s
0 r (tial) s
15 r (dangers) s
17 r (are) s
17 r (few) s
-1 r (er) s
16 r (\(i.e.,) s
17 r (denial) s
17 r (of) s
17 r (service) s
17 r (and) s
16 r (loss) s
17 r (of) s
17 r (rev) s
0 r (en) s
-2 r (ue) s
16 r (as) s
17 r (compared) s
17 r (with) s
0 1506 p 97 c
20 r (wide) s
19 r (range) s
20 r (of) s
20 r (attac) s
-1 r (ks) s
19 r (on) s
20 r (end) s
19 r (systems) s
20 r (through) s
20 r (net) s
0 r 119 c
-2 r (ork) s
19 r (in) s
0 r (terconnection\).) s
32 r (Ho) s
0 r 119 c
-1 r (ev) s
-1 r (er,) s
19 r (con) s
0 r (trolled) s
0 1562 p (net) s
0 r 119 c
-2 r (ork) s
16 r (resource) s
16 r (sharing) s
16 r (is) s
16 r (more) s
17 r (di\016cult) s
16 r (to) s
16 r (supp) s
1 r (ort.) s
24 r (In) s
16 r (an) s
16 r (in) s
0 r (ternet) s
15 r 97 c
17 r (pac) s
-1 r 107 c
-1 r (et) s
15 r (ma) s
0 r 121 c
15 r (tra) s
0 r 118 c
-1 r (el) s
15 r (through) s
0 1619 p 97 c
14 r 110 c
0 r (um) s
-1 r 98 c
0 r (er) s
14 r (of) s
14 r (transit) s
14 r (ADs) s
15 r (on) s
14 r (its) s
14 r 119 c
0 r 97 c
-2 r 121 c
14 r (to) s
14 r (the) s
14 r (destination.) s
20 r (Consequen) s
0 r (tly) s
-4 r 44 c
13 r 112 c
2 r (olicies) s
14 r (from) s
14 r (all) s
14 r (transit) s
14 r (ADs) s
0 1675 p 109 c
0 r (ust) s
15 r 98 c
2 r 101 c
16 r (considered) s
17 r (when) s
16 r 97 c
17 r (pac) s
0 r 107 c
-2 r (et) s
16 r (is) s
16 r 98 c
2 r (eing) s
16 r (sen) s
0 r (t,) s
16 r (whereas) s
16 r (for) s
17 r (stub-AD) s
17 r (con) s
-1 r (trol) s
16 r (only) s
16 r (the) s
17 r 112 c
1 r (olicies) s
17 r (of) s
0 1732 p (the) s
15 r 116 c
-1 r 119 c
-1 r 111 c
14 r (end) s
14 r 112 c
2 r (oin) s
-1 r 116 c
14 r (ADs) s
15 r (ha) s
-1 r 118 c
-1 r 101 c
14 r (to) s
14 r 98 c
2 r 101 c
14 r (considered.) s
20 r (In) s
15 r (other) s
14 r 119 c
0 r (ords,) s
14 r (con) s
0 r (trolled) s
13 r (net) s
0 r 119 c
-1 r (ork) s
13 r (resource) s
15 r (sharing) s
0 1788 p (and) s
13 r (transit) s
13 r (require) s
12 r (that) s
13 r 112 c
2 r (olicy) s
12 r (enforcemen) s
0 r 116 c
12 r 98 c
1 r 101 c
13 r (in) s
0 r (tegrated) s
11 r (in) s
0 r (to) s
12 r (the) s
13 r (routing) s
13 r (proto) s
1 r (cols) s
13 r (themselv) s
-1 r (es) s
12 r (and) s
0 1845 p (can) s
15 r (not) s
15 r 98 c
2 r 101 c
15 r (left) s
15 r (to) s
15 r (net) s
0 r 119 c
-2 r (ork) s
15 r (con) s
-1 r (trol) s
15 r (mec) s
-1 r (hanisms) s
14 r (at) s
16 r (the) s
15 r (end) s
15 r 112 c
1 r (oin) s
0 r (ts.) s
cmr8.1500-13 @sf
1293 1828 p 54 c
22 r 55 c
cmr10.1643-34 @sf
71 1940 p (Complications) s
22 r (also) s
22 r (result) s
22 r (from) s
22 r (the) s
22 r (fact) s
22 r (that) s
22 r (legitimate) s
22 r (users) s
22 r (of) s
22 r (an) s
22 r (AD's) s
23 r (resources) s
22 r (are) s
22 r (not) s
0 1997 p (all) s
21 r (lo) s
1 r (cated) s
21 r (in) s
20 r (that) s
21 r (AD.) s
20 r (Man) s
0 r 121 c
20 r (users) s
21 r (\(and) s
20 r (their) s
21 r (computers\)) s
20 r (who) s
21 r (are) s
21 r (funded) s
20 r 98 c
0 r 121 c
-4 r 44 c
21 r (or) s
21 r (are) s
21 r (a\016liated) s
0 2053 p (with,) s
25 r 97 c
22 r (particular) s
23 r (agency's) s
23 r (program) s
22 r (reside) s
23 r (within) s
22 r (the) s
23 r (AD) s
23 r (of) s
22 r (the) s
23 r (user's) s
23 r (univ) s
-1 r (ersit) s
-1 r 121 c
22 r (or) s
23 r (researc) s
-1 r 104 c
0 2093 p 780 2 ru
cmr6.1500-4 @sf
52 2120 p 54 c
cmr9.1500-18 @sf
69 2136 p (Another) s
13 r (di\013erence) s
13 r (is) s
13 r (that) s
13 r (in) s
13 r (the) s
13 r (in) s
0 r (terconnect) s
12 r (case,) s
13 r (tra\016c) s
13 r (tra) s
0 r 118 c
-1 r (eling) s
12 r 111 c
0 r 118 c
-2 r (er) s
12 r (AD) s
13 r (A's) s
13 r (net) s
0 r 119 c
-1 r (ork) s
12 r (resources) s
13 r (alw) s
0 r 97 c
-1 r (ys) s
12 r (has) s
13 r 97 c
0 2181 p (mem) s
0 r 98 c
(er) s
11 r (of) s
11 r (AD) s
11 r 65 c
10 r (as) s
11 r (its) s
11 r (source) s
11 r (or) s
11 r (destination) s
11 r (\(or) s
11 r 98 c
1 r (oth\).) s
16 r (Under) s
11 r (resource) s
11 r (sharing) s
11 r (arrangemen) s
0 r (ts) s
9 r (mem) s
0 r 98 c
0 r (ers) s
11 r (of) s
11 r 98 c
1 r (oth) s
11 r (AD) s
11 r 65 c
0 2227 p (and) s
13 r 66 c
13 r (are) s
14 r (connected) s
13 r (to) s
13 r (the) s
13 r (same) s
14 r (resources) s
13 r (and) s
13 r (consequen) s
0 r (tly) s
12 r (in) s
0 r (tra-AD) s
13 r (tra\016c) s
13 r (\(i.e.,) s
13 r (pac) s
0 r 107 c
-1 r (ets) s
12 r (sourced) s
cmti9.1500-21 @sf
13 r (and) s
cmr9.1500-18 @sf
14 r (destined) s
13 r (for) s
0 2272 p (mem) s
0 r 98 c
(ers) s
14 r (of) s
13 r (the) s
14 r (same) s
14 r (AD\)) s
14 r (tra) s
-1 r 118 c
-1 r (els) s
13 r 111 c
0 r 118 c
-1 r (er) s
13 r (the) s
13 r (resources.) s
20 r (This) s
14 r (distinction) s
14 r (is) s
13 r (relev) s
-1 r (an) s
-1 r 116 c
13 r (to) s
14 r (the) s
13 r (writing) s
14 r (of) s
14 r 112 c
1 r (olicies) s
13 r (in) s
14 r (terms) s
0 2318 p (of) s
13 r (principal) s
13 r (a\016liation.) s
cmr6.1500-4 @sf
52 2348 p 55 c
cmr9.1500-18 @sf
69 2364 p (Economies) s
16 r (of) s
16 r (scale) s
15 r (is) s
16 r (one) s
16 r (motiv) s
-1 r (ation) s
15 r (for) s
15 r (resource) s
16 r (sharing.) s
26 r 70 c
-2 r (or) s
15 r (example,) s
16 r (instead) s
16 r (of) s
16 r (in) s
0 r (terconnecting) s
15 r (separately) s
0 2409 p (to) s
14 r (sev) s
0 r (eral) s
13 r (indep) s
1 r (enden) s
0 r 116 c
13 r (agency) s
14 r (net) s
0 r 119 c
-1 r (orks,) s
13 r 97 c
14 r (campus) s
14 r (net) s
0 r 119 c
-1 r (ork) s
13 r (ma) s
0 r 121 c
13 r (in) s
0 r (terconnect) s
12 r (to) s
14 r 97 c
14 r (shared) s
14 r (bac) s
0 r (kb) s
0 r (one) s
14 r (facilit) s
0 r 121 c
-3 r 46 c
20 r 84 c
-3 r 111 c
1 r (da) s
-1 r 121 c
-3 r 44 c
0 2455 p (in) s
0 r (terconnection) s
13 r (is) s
15 r (ac) s
0 r (hiev) s
-1 r (ed) s
13 r (through) s
15 r 97 c
14 r (com) s
0 r (bination) s
14 r (of) s
14 r (AD) s
15 r (sp) s
1 r (eci\014c) s
14 r (and) s
15 r (shared) s
14 r (arrangemen) s
0 r (ts.) s
21 r 87 c
-2 r 101 c
14 r (exp) s
1 r (ect) s
14 r (this) s
15 r (mixed) s
0 2501 p (situation) s
12 r (to) s
12 r 112 c
1 r (ersist) s
11 r (for) s
12 r (\\w) s
0 r (ell-connected") s
11 r (campuses) s
12 r (for) s
11 r (reasons) s
12 r (of) s
12 r 112 c
1 r (olitics,) s
12 r (economics,) e
the first fragment as large as possible.
- Illegal Source Address
It has been suggested that a gateway should not forward a packet
Braden [Page 19]
RFC 1127 Perspective on Host Requirements October 1989
containing an illegal IP source address, e.g., zero.
- Option Processing
Specific rules should be given for the order of processing
multiple options in the same IP header. Two approaches have been
used: to process options in the order presented, or to parse them
all and then process them in some "canonical" order.
The legality should also be defined for using broadcast or
multicast addresses in IP options that include IP addresses.
Security Considerations
A future revision of the Host Requirements RFCs should incorporate a
more complete discussion of security issues at all layers.
Author's Address
Robert Braden
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292-6695
Phone: (213) 822 1511
EMail: Braden@ISI.EDU
Braden [Page 20]